くらめその情シス：小ネタ：ActiveDirectoryサーバ更新時のWorkSpaces DNS設定にご注意を
どうも、情シスやってます アノテーション の徳道です。
以前、ActiveDirectoryのサーバを更新をしたときにAzure AD Connectorの設定を変更するポイントを紹介しました。
社内ではActive Directoryサーバと連動するAWS Dirctory Serviceを用いてAmazon WorkSpacesを利用しています。
こちらも一見、設定が不要そうで実は目立たないところに変更が必要な場所がありましたので、こちらも小ネタとして紹介いたします。
AWS Directory Serviceの変更ポイント
弊社ではActive DirectoryサーバをEC2インスタンスとして起動し、AWS Directory ServiceのAD ConnectorでWorkSpacesにユーザー認証を提供しています。
Active Directoryサーバの更新時の影響調査で目に見える変更必要なポイントはここです。
一般的にはActive DirectoryはVPCのPrivateサブネットにホストされ、DNSサーバを兼ねていることが多いと思います。
このIPアドレス設定をひとまず新しいADサーバにすることですね。もちろん、別途DNSサーバを立てていて、
_ldap._tcp.<DnsDomainName> と _kerberos._tcp.<DnsDomainName> SRV レコードの名前解決ができていれば、この設定変更は不要です。
ここだけ変更しておけばよい…そんなふうに考えていた時期が私にもありました。
だがしかし、旧ADサーバを停止して既存のWorkSpacesを起動しても認証でエラーになってしまい、WorkSpacesへログインができなかったのです。
新規に作成したWorkSpacesは問題なくログインができていました。
旧Active Directoryサーバを起動すると既存のWorkSpacesもログインができるようになりました。
実はWorkSpacesの内部にもDNSサーバの情報が設定されていた
これはWorkSpacesのインスタンス側で何か情報を持っているに違いない…と仮定していろいろ調べてみます。
結果、やはり既存のインスタンスにはDNSサーバとして旧DNSサーバのIPアドレスが設定されていることが分かりました。
これはActiveDirectoryの以下のグループポリシーで設定しておくことで、一度WorkSpacesを再起動すれば反映されるとのこと。
なおこの情報は弊社 Classmethod Members のサポートからもたらされました！感謝。
レジストリキー：HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\SkyLight
値：DomainJoinDns 10.xxx.xxx.xxx,10.xxx.xxx.yyy
弊社ではグループポリシーのDefault Domain Policyに設定しています。
「コンピューターの構成」→「基本設定」→「Windowsの設定」→「レジストリ」
値のデータは優先DNS、代替DNSをカンマで区切って記載します。
この設定をしておき、マネージメントコンソールでWorkSpacesを一旦「停止」→「起動」することで、旧ADサーバを停止していても既存のWorkSpacesインスタンスで認証が正しく行われるようになりました。
なぜかWorkSpacesの再起動ではグループポリシーが反映されなかったので、明示的に停止・起動をしておくといいかもしれません。
おわりに
WorkSpacesも内部でActive Directoryサーバを参照していることが分かりました。分かってみればWindowsの仕組み上まぁそうだよなぁ、とナットクするところも、なかなか普段気にしていないところに設定が潜んでいると気が付かないものですね。
WorkSpaces管理をされている管理者の方の一助になれば！と思います。
それではまた次の記事でお会いしましょう。
